The architecture that leverages policy charging control mechanisms is defined by a 3GPP (Third Generation Partnership Project) TS 23.203 (v.12.3.0) which is depicted in FIG. 1.
A Policy and Charging Rules Function (PCRF) 10 is the functional element that encompasses policy control decision and flow based charging control functionalities. It provides network and gating control, and manages the flow based charging. Via the Diameter Gx interface, using Policy and Charging Control (PCC) rules, the PCRF 10 instructs a Policy and Charging Enforcement Function (PCEF) 51 provided in a gateway 50 regarding the treatment of each service data flow.
Over its basic functionalities described in the last paragraph, the PCRF can receive session and media related information from an Application Function (AF) 20.
The AF 20 is an element offering applications the control of IP bearer resources and is able in that way to require differentiation of Quality of Service (QoS) for such applications. This entity shall communicate with the PCRF 10 to transfer session information (i.e. service information with description of the media to be delivered in the transport layer). This communication is performed using the Diameter Rx interface.
The AFs 20 may be deployed by the operator of the communication network or, more precisely, by the operator offering the IP connectivity access network (IP-CAN), as presented at FIG. 1, or may be provided by an external third party service provider, as presented at FIG. 2 and further discussed.
The operator of the communication network may further be referred to as a communication network operator or, for the sake of simplicity, as a network operator, and both terms may indistinctly be used in the following unless otherwise specified.
The policy and charging information is determined based on the subscriber requesting the flow wherein the subscriber information of the corresponding rules are retrieved from a Subscription Profile Repository (SPR) 30. The PCRF 10 is furthermore connected to a Bearer Binding and Event Reporting Function (BBERF) 60 and an Online Charging System (OCS) 40. A traffic detection function 71 is provided to detect traffic and furthermore an Offline Charging System (OFCS) 80 is provided.
To accommodate another case, 3GPP TS 29.201 v12.1.0 also provides an XML-based interface between the AF 20 and the PCRF 10, as shown in FIG. 2. This another case fits the scenario commented above wherein the AF is provided by an external third party service provider. The Representational State Transfer (REST) reference point resides between the AF 20 and a Protocol Converter (PC) 90. In particular, the REST-Rx term is used to indicate the Rx interface based on REST between the AF and the PC. The PC 90 converts application level information received from the AF to diameter session information and communicates with the PCRF 10 via the diameter based on the Rx reference point. The Policy and Charging Control (PCC) architecture, the PCRF and the AF are described in further detail in 3GPP TS 23.203 and the diameter Rx reference point is described in 3GPP TS 29.214 v12.6.0.
For the sake of clarity, the terms ‘third party entity’ and ‘partner entity’ represent an AF provided by an external company or operator, other than the operator of the communications network, and they may indistinctly be used in the following unless otherwise specified.
Likewise, the terms ‘external third party service provider’, ‘third party’, ‘third party enterprise’ and ‘partner’ represent an external company or operator, other than the operator of the communications network, and they all may indistinctly be used in the following unless otherwise specified.
One of the services is the dynamic rule provisioning in real-time, which allows a customer of the network to partner with third parties, such as over the top (OTT) service providers and enterprises, for a particular treatment of a data packet flow. The dynamic rule provisioning service requires that an offline agreement or communication takes place between the network operator and its partner, where the partner indicates:                Identifier(s) of the application(s) running the partner service(s), together with type of media, bandwidth, IP address and port numbers. This is the 3GPP TS 29.214 calls ‘service information’.        Different treatment for the same service per user or group of users so that different QoS and Charging values are assigned, for different groups of users. This feature is optional. This is what the 3GPP TS 29.214 addresses when it states that the PCRF may use the subscription information as basis for the policy and charging control decisions.        
This offline agreement is configured in the PCRF 10 in terms of internal policies, static information and subscriber provisioning, which is used later on during the dynamic rule provisioning service execution in real time (i.e., when processing an authorization request received at the PCRF from the AF via the Rx interface).
The above situation is explained with the following example.
The company XYZ, in order to request a particular and differentiated bandwidth, priority or charging for the Corporate Lync Messaging, it needs to agree with the operator of the communications network the Application Function Identifier (AFId) “XYZA” that will identify the company, and the media types their services will use.
For service differentiation, the company XYZ indicates the users it has, which QoS (Quality of Service) and Charging value sets it is going to require, and which set of values apply to each subscriber.
It is assumed that the company XYZ might want all their employees to be charged according to the company rates in business hours for the Corporate Lync Messaging, except those assigned to specific critical projects, which would not have time restrictions. The operator needs to provision different conditions and policies for employees working in standard projects and for employees working in critical projects.
If e.g. security personnel and critical projects have higher priority and higher bandwidth for Corporate Lync Service, the operator has to provision beforehand the QoS policies to apply to the Corporate Lync Service for the company XYZ security personnel and the people assigned to the critical project.
The existing PCC architecture presented in the Technical Background chapter has proved to be effective so far, covering the major use cases required nowadays by the market. But the market is changing, and services evolution is denouncing important limitations, coming along with complex use cases that are no longer fully covered by the standardized PCC architecture.
Coming back to the previous example of the XYZ company, in the case that one employee assigned to a critical project is re-assigned to a new regular project, with the current procedures there is the need for the XYZ company to request the network operator to modify the conditions and policies for this particular employee.
Accordingly, a need exists to increase the flexibility when a policy rule is selected for a data packet flow.